You are defining, based on the product identifier of the registered base product, to infer which other products / repositories the system can use. That works, but is a lot of manual setup.

Maybe there is an automatic way to find out that information, in the way how SCC is doing this:
In SCC, the used subscription of the base product has a list of product classes. The system then has 'permission' to use all products that have a product class of that list. Example: a SUMA subscription includes the product classes of SLES (7261), SLE Micro (MICROOS-X86).

We have a manual config to build that connection for test subscriptions: https://github.com/SUSE/happy-customer/blob/master/glue/config/multi_product_classes.yml

Just an idea, maybe this is a less manual, and more aligned with SCC way how to define access permission.

You are defining, based on the product identifier of the registered base product, to infer which other products / repositories the system can use. That works, but is a lot of manual setup.

Maybe there is an automatic way to find out that information, in the way how SCC is doing this: In SCC, the used subscription of the base product has a list of product classes. The system then has 'permission' to use all products that have a product class of that list. Example: a SUMA subscription includes the product classes of SLES (7261), SLE Micro (MICROOS-X86).

We have a manual config to build that connection for test subscriptions: https://github.com/SUSE/happy-customer/blob/master/glue/config/multi_product_classes.yml

Just an idea, maybe this is a less manual, and more aligned with SCC way how to define access permission.

@digitaltom It is a good idea, however, when I tested that, the subscription identifier in the activated products for the stand-alone SLE Micro (not SUMA) system was nil